MQTT 介紹

昨天介紹基本的雲端連結方式非常基本，今天來介紹真正因應 IoT 而生的 MQTT(Message Queuing Telemetry Transport).

起源

MQTT 消息隊列遙測傳輸(Message Queuing Telemetry Transport)是 ISO 標準(ISO/IEC PRF 20922)下基於發布/訂閱範式的消息協議。它工作在 TCP/IP 協議族上，是為硬體性能低下的遠程設備以及網絡狀況糟糕的情況下而設計的發布/訂閱型消息協議，為此，它需要一個消息中間件 。
為何說是硬體性能低下，因為應用場景在 IoT 的應用需要考慮在低耗電長時間待命的狀態下在短時間內完成資料傳送過程。
以及網絡狀況糟糕，因為地處偏遠訊號複雜狀態下會做訊息傳送與接收的確認。

特點介紹

• 連接: 等待與伺服器建立連接然後創建節點之間的連接.
• 斷開連接: 待 MQTT 客戶端完成所必須完成的工作，然後等待 TCP/IP 會話關閉連接。
• 發布: 將請求傳遞給 MQTT 客戶端後立即返回到應用程式執行緒。
• 服務品質(QOS)
  • 服務品質: 服務品質指的是交通優先級和資源預留控制機制，而不是接收的服務品質。 服務品質是為不同應用程式，用戶或數據流提供的不同優先級的能力，或者也可以說是為數據流保證一定的性能水平的能力。
  • 以下是每一個服務品質級別的具體描述
    • 0: 最多一次傳送 (只負責傳送，發送過後就不管數據的傳送情況)
    • 1: 至少一次傳送 (確認數據交付)
    • 2: 正好一次傳送 (保證數據交付成功)

mqtt 基本架構

優點

與一般的 HTTP RESTful 放式差異:

• 持續性連接： 不是 Http 每次發送查詢都需要連線。
• 可以追蹤連線狀態: 因為上一點的關係，所以可以做到即時的連線狀態顯示確認。
• 資料封包小：最小封包只有 2 byte 表頭 + 可變表頭 (not always present)+ payload (not always present).
  
• 輕量級的 machine-to-machine 通信協議(M2M)。publish/subscribe 模式。基於 TCP/IP。支持 QoS。適合於低帶寬、不可靠連接、嵌入式設備、CPU 內存資源緊張。FacebookMessenger 採用了 MQTT。MQTT 有可能成為物聯網的重要協議。
• 客戶端/端點透過發布/訂閱消息: 不用做輪巡等動作減少封包與請求，只要等待消息。

MQTT Protocol Commands

角色

• Publisher 發布者: 通常為偵測被動元件端點使用，像是之前做的溫度監控那溫度回傳部分他就是偵測元件。那如果還有其他偵測元件一班都是使用這個。
• Broker 代理人: 這邊就是指 服務器端 專門負責數以百萬計的 Client 客戶端。
• Subscriber 訂閱者: 這邊多指為需要資訊的接收端，如手機或網頁段。

真實情境

今天我要控制一個馬達，此時馬達的控制元件會同時是 Subscriber 與 Publisher，如㪋説呢這個馬達會發布（Publisher）他的狀態值 ON/OFF 同時接收（Subscriber）控制訊號。
那我的使用用者要知道馬達狀態他就是接收（Subscriber）控制訊號且他會控制馬達所以發布（Publisher）狀態值 ON/OFF。

那我今天有幾百個馬達要控制，我們可以透過代理人（Broker）來同時訂閱整個層級的馬達。

結語

透過介紹相信大家可以想像同時控制大量裝置，或者同時接收大量裝置的資料都不是夢想了！

參考

wikipedia MQTT

Understanding the MQTT Protocol Packet Structure

今天就到這了感謝收看

Blog 同步刊登